System and method of a passphrase account identifier for use in a network environment

ABSTRACT

A system and method for facilitating a financial transaction over a network including use of a passphrase account identifier is described herein. In one embodiment, a system for facilitating a financial transaction over a network comprises a communication interface; and a payment provider system configured to receive via the communication interface a passphrase account identifier from a merchant system, match the passphrase account identifier to a corresponding funding instrument number of a corresponding funding instrument, communicate the corresponding funding instrument number to an issuer system, receive from the issuer system a notification indication of one of acceptance of the funding instrument or decline of the funding instrument, and communicate back to the merchant system the notification indication.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims benefit of priority toU.S. application Ser. No. 14/027,062, filed Sep. 13, 2013, which is acontinuation of U.S. application Ser. No. 13/523,727, filed Jun. 14,2012, now U.S. Pat. No. 8,538,877, issued Sep. 17, 2013, which is acontinuation of U.S. application Ser. No. 11/966,875, filed Dec. 28,2007, now U.S. Pat. No. 8,214,288, issued Jul. 3, 2012, all of which areincorporated herein by reference in their entirety.

BACKGROUND

1. Field of the Invention

The present invention generally relates to financial transactions andmore particularly to a passphrase account identifier for use in afinancial network.

2. Related Art

In direct (face-to-face) or online financial transactions, customerssearch for and purchase products and services from a merchant. In thecase of online shopping, transactions are conducted through electroniccommunications with online merchants over electronic networks, such asthe Internet. During the course of these transactions, customers mayprovide payment in various ways including, for example, credit cards,electronic fund transfers, and other payment techniques offered bypayment providers.

Typically, when online shopping at a particular website, customersselect items to purchase by clicking on a link for a specific item. Whendone shopping, the customer proceeds to a checkout page to provide someform of payment information such as credit card information for theselected items.

Similarly, during checkout in a face-to-face transaction the customer istypically required to provide some form of payment information such ascredit card information for the selected items. As the customercontinues shopping and is ready to purchase items from other merchantwebsites or from other merchants directly, the process of providingpayment information such as credit card information to complete thepurchase transaction is repeated.

In this regard, multiple funding instruments including credit cards suchas merchant specific credit cards, as well as, credit cards to satisfy avariety of accounting purposes including one or more cards for businessrelated purchases and one or more cards for personal related purchasesmay be carried by the customer. Accordingly, the necessity to retrieve aparticular card is often cumbersome and inconvenient, while trying toremember and recall the sixteen-digit credit card number so that thecard number and its associated credit card information may be verifiedand authorized is extremely difficult and more often than not results inan error in card authorization as the card numbers are not accuratelyrecalled and communicated to the merchant system.

Accordingly, there exits a need for a passphrase account identifier foruse as a funding instrument number substitute in a financial network.

SUMMARY

For purposes of summarizing the disclosure, exemplary embodiments of asystem and method for facilitating a financial transaction over anetwork including a passphrase account identifier have been describedherein.

In one embodiment, a system for facilitating a financial transactionover a network comprises a communication interface; and a paymentprovider system configured to receive via the communication interface apassphrase account identifier from a merchant system, match thepassphrase account identifier to a corresponding funding instrumentnumber of a corresponding funding instrument and associated fundinginstrument account, authorize the funding instrument, and indicatenotification of one of acceptance of the funding instrument or declineof the funding instrument back to the merchant system.

In another embodiment, a system for facilitating a financial transactionover a network comprises a communication interface; and a paymentprovider system configured to receive via the communication interface apassphrase account identifier from a merchant system, match thepassphrase account identifier to a corresponding funding instrumentnumber of a corresponding funding instrument, communicated thecorresponding funding instrument number to an issuer system, receivefrom the issuer system a notification indication of one of acceptance ofthe funding instrument or decline of the funding instrument, andcommunicate back to the merchant system the notification indication.

In still another embodiment, a method for facilitating a financialtransaction over a network comprises receiving via the communicationinterface a passphrase account identifier from a merchant system;matching the passphrase account identifier to a corresponding fundinginstrument number of a corresponding funding instrument and associatedfunding instrument account; authorizing the funding instrument; andindicating notification of one of acceptance of the funding instrumentor decline of the funding instrument back to the merchant system.

These and other embodiments will be more readily apparent from thedetailed description of the embodiments set forth below taken inconjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of a network system configured tofacilitate online financial transactions.

FIG. 2 shows a block diagram including a passphrase account identifierfor use as a funding instrument number substitute in a networkenvironment in accordance with one embodiment.

FIG. 3 shows a block diagram including a passphrase account identifierfor use as a funding instrument number substitute in a networkenvironment in accordance with another embodiment.

FIG. 4 shows a block diagram including a passphrase account identifierfor use as a funding instrument number substitute in a networkenvironment in accordance with still another embodiment.

FIG. 5 shows a block diagram including a passphrase account identifierfor use as a funding instrument number substitute in a networkenvironment in accordance with another embodiment.

FIG. 6 shows one embodiment of a method for facilitating a financialtransaction over a network including a passphrase account identifier inreference to a payment provider system.

Embodiments of the disclosure are understood by referring to thedetailed description that follows. It should be appreciated that likereference numerals are used to identify like elements illustrated in oneor more of the figures, wherein showings therein are for purposes ofillustrating embodiments and not for purposes of limiting the same.

DETAILED DESCRIPTION

Exemplary embodiments will now be described with references to theaccompanying figures, wherein like reference numbers refer to likeelements throughout. The terminology used in the description presentedherein is not intended to be interpreted in any limited or restrictivemanner simply because it is being utilized in conjunction with adetailed description of certain embodiments.

Embodiments of the present disclosure are described herein as they mayrelate to an electronic payment system environment. An electronicpayment system is generally considered as any kind of network servicethat includes the exchange of money for goods or services. Such networkpayment system includes, for example, card systems such as a creditand/or debit card processing system for facilitating an online orweb-based financial transaction. However, persons of ordinary skill inthe art will understand that the teachings of the present disclosureapply equally to a financial transaction that occurs directly between abuyer and a merchant such as in a face-to-face transaction that mayoccur in department store or similar type business environment.

In one embodiment, the network may be implemented as a single network ora combination of multiple networks. For example, in various embodiments,the network may include the Internet and/one or more intranets, landlinenetworks, wireless networks, and/or other appropriate types ofcommunication networks. In another example, the network may comprise awireless telecommunications network (e.g., cellular phone network)adapted to communicate with other communication networks, such as theInternet.

As generally shown in FIG. 1, a network system such as a card system 100may include a client system 120 (also referred to as a “user” systemherein), a merchant system 140 having a merchant provided website 141for the sale of goods and/or services, a payment provider system 180,and a card issuer system 170, wherein the flow of information and moneybetween the parties in the financial transaction occurs along a network160 such as the Internet.

Generally, in the card system 100, a user 102 (e.g., “buyer”, “client”,or “cardholder”) is issued credit 30 after an account has been approvedby an issuer system 170 such as a financial institution (bank) or otherorganization. The issuer system 170 registers the user 102, issues acard(s), and operates a card account 172 to which payments can becharged. The user 102 is able to make purchases with the card forproducts and/or services from a merchant system 140 accepting the cardup to a pre-established credit limit.

For simplicity and ease of describing the subject matter, thedescription that follows uses a credit card system as an example of anetwork payment system in which use of passphrase account identifier asdescribed herein may be applicable. Persons of ordinary skill in the artwill understand that other network payment systems wherein a card havinga number(s) as an identifying feature that is used for verification,authorization, and other purposes may be used within the scope of thedisclosure.

In a typically financial transaction, the user 102 chooses one ofmultiple funding instruments 40, such as a credit card, to pay for thepurchase of an item (product and/or service) and the merchant system140and submits the card number for authorization 45 either verbally or bylocating and swiping the credit card at a point-of-sale device. Theissuer system 170 may act directly with the merchant system 140 forcredit card authorization. However, as there are many issuer systems, itis generally more efficient for a payment provider system 180 to providecard services to the merchant system 140. In this regard, the merchantsystem 140 establishes a connection with the payment provider system180. Connections may be made through an application programminginterface (API) for card verification and processing. The APIs aregenerally HTTP or TCP/IP based and provide a relatively simple interfaceto communicate with the merchant's application software.

In this regard, the payment provider system 180 may provide paymentprocessing for online transactions on behalf of the user 102 so that theuser 102 does not expose his payment information directly to themerchant system 140. Instead the user 102 registers his accountinformation with the payment provider system 180, maps the account to anemail address, and then uses the payment provider system 180 to makepurchases when redirected to the payment provider system 180 from themerchant's site 141. After the transaction is authorized 45 the paymentprovider system 180 completes the online transaction, while the user 102is directed back to the merchant's site 141 to an order confirmationpage.

More specifically, the client system 120 may include one or more browserapplications 122 which may be used, for example, to provide a userinterface to permit the user 102 to browse information available overthe network 160; one or more toolbar applications 124 displaying agraphical user interface (GUI) in connection with the browserapplication 122 to provide client-side processing for performing tasksin response to operations selected by the user 102; and a serviceapplication 126 comprising a software program for facilitating financialtransactions, e.g., the direct purchase of items (products and/orservices) on the network 160.

The service application 126 typically comprises a software program, suchas the GUI, executable by a processor that is configured to interfaceand communicate with the one or more merchant systems 140 and thepayment provider system 180 via the network 160. The service application126 is configured to provide and display a payment mechanism, such animage or icon, on a display component (e.g., monitor) of the clientsystem 120. The user 102 is able to access merchant websites 141 viamerchant systems 140 to view and select items for purchase bycommunicating with the payment provider 180.

The client system 120 may include other applications 128 as may bedesired in particular embodiments to provide additional featuresavailable to the user 102. For example, such other applications 128 mayinclude security applications for implementing client-side securityfeatures, programmatic client applications for interfacing withappropriate application programming interfaces (APIs) over the network160 or various other types of generally known programs and/orapplications.

The client system 120 may include one or more user identifiers 130,which may be implemented, for example, as operating system registryentries, cookies associated with the browser application 122,identifiers associated with hardware of the client system 120, orvarious other appropriate identifiers. The user identifier 130 mayinclude attributes related to the user, such as personal information andbanking information including credit card number. In variousimplementations, the user identifier 130 may be passed with a userpurchase request to the payment provider 180, and the user identifier130 may be used by the payment provider 180 to associate the user 102with a particular user account maintained by the payment provider 180.

As shown in FIG. 1 and FIG. 2, one or more merchant systems 140-142 aremaintained by merchants 104 offering various items (products and/orservices) in exchange for financial payment or other consideration to bereceived from users, such as user 102, over the network 160. In thisregard, each one of the one or more merchant systems 140-142 may includea database 143 for identifying available products and/or services, whichmay be made available to the client system 120 for viewing and purchaseby the user 102. Accordingly, each of the merchant systems 140-142 mayinclude a marketplace application 144 configured to provide informationover the network 160 to the browser application 122 of the client system120. For example, the user 102 may interact with the marketplaceapplication 144 through the browser application 122 over the network 160to search and view various items, products and/or services identified inthe database 143.

Each of the one or more merchant systems 140-142 may include a checkoutapplication 146 configured to accept payment information from the user102 and/or from the payment provider system 180 over the network 160 tofacilitate online transactions of products and/or services identified bythe marketplace application 144.

Each of the one or more merchant systems 140 may include one or moremerchant identifiers 148, which may be included as part of the one ormore items made available for purchase so that a particular item may beassociated with a particular merchant 104. The merchant identifier 148may include attributes related to the merchant 104, such as business andbanking information. In various implementations, the merchant identifier148 may be passed with a user purchase request to the payment providersystem 180 when the user 102 selects a item for purchase and processing,and the merchant identifier 148 may be used by the payment providersystem 180 to associate a particular item purchased with a particularmerchant account maintained by the payment provider system 180.

Each of the one or more merchants 104 having a related merchant system140-142 may need to establish a merchant account 184 with the paymentprovider system 180 so that the payment provider system 180 is able toprocess transactions having items offered for purchase by the merchants104. When establishing a merchant account 184, each of the one or moremerchants 104 may need to provide business information, such as name,address, phone number, etc., and financial information, such as bankinginformation, merchant account information, credit card information,payment processing information, etc.

Each of the one or more merchant systems 140-142 may be associated witha particular link (e.g., a link, such as a URL (Uniform ResourceLocator) to an IP (Internet Protocol) address). In this regard, thepayment provider system 180 may optionally redirect the browserapplication 122 to an appropriate webpage and/or merchant site 141 ofthe merchant system 140 to facilitate purchase of a corresponding itemmade available from at least one of the merchant systems 140.

Each one of the merchant systems 140-142 may further be configured toinclude and maintain a plurality of user accounts 149, each of which mayinclude account information 150 associated with individual users. Forexample, account information 150 may include private financialinformation of user 102, such as one or more account numbers, passwords,credit card information, banking information, or other types offinancial information, which may be used to facilitate onlinetransactions between the user 102 of the client system 120 and one ormore merchants systems 140-142. In various embodiments, the methods andsystems described herein may be modified to accommodate users that mayor may not be associated with at least one existing user account and/ormerchant account, respectively.

Alternatively, as indicated above, the payment provider system 180 mayprovide payment processing for online transactions on behalf of the user102 to an operator of the merchant system 140. In this regard, thepayment provider system 180 includes one or more payment applications182, which may be configured to interact with the client device 120and/or each of the merchant systems 140-142 over the network 160 tofacilitate the purchase of items by the user 102 from the merchantsystems 140-142.

The payment provider system 180 may be configured to maintain aplurality of user and merchant accounts 184, each of which may includeaccount information 186 associated with individual users 102 and the oneor more merchants 104 associated with the merchant systems 140-142. Forexample, account information 186 may include private financialinformation of user 102 and/or merchants 104, such as one or moreaccount numbers, passwords, credit card information, bankinginformation, or other types of financial information, which may be usedto facilitate online transactions between the user 102 of the clientsystem 120 and one or more merchants 104 associated with the merchantsystems 140-142. As such, the payment application 182 may be configuredto interact with the one or more merchant systems 140-142 on behalf ofthe user 102 during a transaction with checkout application 146 withoutrequiring the user 102 to provide account information 186 directly tothe merchant systems 140-142. In various embodiments, the methods andsystems described herein may be modified to accommodate users and/ormerchants that may or may not be associated with at least one existinguser account and/or merchant account, respectively.

As shown in FIG. 1, in one method for conducting a client-side onlinetransaction the service application 126 may be installed and run on theclient system 120 to allow the client system 120 to communicate with oneor more of the merchant systems 140-142 via the network 160 to select anitem for purchase.

Likewise, the service application 126 allows the client system 120 tofurther communicate with the payment provider system 180 to processonline purchase requests for items selected for purchase and processingin a financial transaction.

As indicated above, the user 102 may run the browser application 122 onthe client system 120 to access at least one merchant website 141 via arelated merchant system 140 to search the accessed merchant website 141and view one or more items for purchase.

The user 102 may, for example, generate a purchase request for an itemat the merchant's site 141. The purchase request may include userinformation, merchant information, and selected item informationembedded as arguments in an expression that are passed to the paymentprovider system 180. The user information may include user identifierinformation, the merchant information may include the merchantidentifier information, and the selected item information may includeone or more image attributes, including item identifier information,having dynamic arguments identifying the item and the merchant providingthe item.

The payment provider system 180 receives the purchase request includingcredit card data from the user 102 via the client system 120. Next, thepayment provider system 180 verifies the user account informationincluding user identification provided by the user 102 in the purchaserequest with user information stored in payment provider system 180.

In this regard, the payment provider system 180 validates the card andcommunicates with the issuer system 170 to verify the amount for thetransaction is available in the customer's account 174. Alternatively,as indicated above, the merchant system 140 may communicate with theissuer system 170 to obtain credit card authorization. In either case,if the card is good and the funds are available, an approvednotification indication or message is sent back to the merchant system140. If the card is bad or if funds are not available, a declinednotification indication or message is sent back to the merchant system140.

Once proper user identification has been provided and/or verified, andthe funding instrument has been authorized the online purchase may becompleted by deducting the amount of the purchase request from the useraccount and crediting the amount of the purchase request to the merchantaccount.

As indicated above, in many financial transactions online orface-to-face, such as those that typically occur when a merchant managesa cash register and/or a point-of-sale (POS) system, a user attemptingto purchase an item may be carrying multiple funding instrumentsincluding credit cards such as merchant specific credit cards, as wellas, credit cards to satisfy a variety of accounting purposes includingone or more cards for business related purchases and one or more cardsfor personal related purchases. Accordingly, the necessity to retrievethe card is often cumbersome and inconvenient, while trying to rememberand recall the sixteen-digit credit card number so that the credit cardaccount may be verified and authorized is extremely difficult and moreoften than not results in an error in card authorization as the cardnumbers are not accurately recalled and communicated to the merchantsystem.

Embodiments of the disclosure overcome the above-mentioned difficultiesof retrieving a credit card or remembering a credit card number byproviding a passphrase account identifier as an easily rememberedsubstitute for the sixteen digit credit card number to enable users toconduct a payment transaction in more efficient manner. Accordingly,subject matter described herein permits a user to dispense with carryingpayment cards and the above-mentioned problems generally associated withthe cards by essentially providing a “cardless wallet”.

As indicated above, in order to obtain credit, i.e., receive creditapproval and establish a credit card account 172 with the issuer system170 and/or establish a user account 184 with the payment provider system180, the user 102 is typically required to provide private financialinformation such as one or more account numbers, passwords, other creditcard information, banking information, or other types of financialinformation, as well as, personal information such as name, age,residence location, etc. which may be stored in the correspondingidentification database 176, 187 and used to facilitate onlinetransactions.

In accordance with one embodiment, during the process of establishingvarious credit card or similar type of funding instrument accounts witheither the payment provider system 180 and/or the issuer system 170 theuser 102 is prompted to provide a passphrase account identifier 121 as arelatively more easily remembered substitute for the sixteen digitcredit card number 123 to enable users to conduct a payment transactionin more efficient manner.

For example, when establishing a Visa® account with the issuer system170, the user may indicate that the passphrase “BigSpender”, “4121979”(indicating an easily remembered date), or any alpha-numericalcombination that is not less than a specified minimum number ofcharacters and not greater than specified maximum number of charactersis to be used in place of the actual credit card number 123 whencompleting a purchase or other type of transaction that requires creditcard information to be provided by the user. For at least transactionand identification purposes, the passphrase is essentially an identifierused by the payment provider system 180 and/or issuer system 170 toidentify the user's credit card number 123. In a similar manner, apassphrase account identifier 121 may be assigned or designated by theuser 102 for each credit card number. Accordingly, instead of attemptingto recall or remember the sixteen digits of one or more credit cards,the user 102 is only required to recall or remember a relatively simpleand more familiar/personal passphrase account identifier 121.

FIG. 2 shows a block diagram of a passphrase account identifier for usein a network environment in accordance with one embodiment. In an onlinefinancial transaction, as indicated above, one or more browserapplications 122 may be used to provide a user interface to permit theuser 102 to browse information available over the network 160; one ormore toolbar applications 124 displaying a graphical user interface(GUI) in connection with the browser application 122 to provideclient-side processing for performing tasks in response to operationsselected by the user 102; and a service application 126 comprising asoftware program for facilitating the financial transactions, e.g., thedirect purchase of items (products and/or services) on the network 160.

At the time of online checkout, i.e., purchase of item, verification andauthorization of credit, etc., the user 102, in lieu of the credit cardnumber 123, provides the merchant system 140 with the passphrase accountidentifier 121 chosen by the user 102 to represent the credit cardnumber 123 corresponding to a particular credit card account.

Once received by merchant system 140, the passphrase account identifier121 may be communicated, as indicated by reference “A”, via the network160 to the issuer system 170 where the passphrase account identifier 121is matched to user information including the corresponding credit cardnumber 123 and the associated credit card account 172. In oneembodiment, as encryption and decryption techniques and/or technology isnot required, the process of matching passphrase account identifier 121to the corresponding credit card number 123 and its associated account172 is not unlike matching of any other data related to the user 102 andvarious account information. Once the credit card number 123 isretrieved, the associated credit card account 172 may be verified andauthorized for acceptance or decline by the issuer system 170; theresult of which are then communicated back to the merchant system 140 sothat the purchase transaction may be completed.

Likewise, persons of ordinary skill in the art will understand that thepayment provider system 180 may maintain various credit accounts 186such that once the passphrase account identifier 121 is received by thepayment provider system 140 via the network 160 the passphrase accountidentifier 121 may be matched to a corresponding credit card number 123and its associated credit account 186 to facilitate acceptance ordecline of the credit transaction by the payment provider system 140.

In an alternative embodiment shown in FIG. 2, the user 102 proceeds toonline checkout, i.e., purchase of item, verification and authorizationof credit, etc., where once again the user 102, in lieu of the creditcard number, provides the merchant system 140 with the passphraseaccount identifier 121 chosen by the user 102 to represent a credit cardnumber 123 corresponding to a particular credit card account.

Once received by merchant system 140, the passphrase account identifier121 may be communicated, as indicated by reference “B”, via the network160 to the payment provider system 180 where the passphrase accountidentifier 121 is matched to user information including thecorresponding credit card number 123. In one embodiment, once again, asencryption and decryption techniques and/or technology is not required,the process of matching passphrase account identifier 121 to thecorresponding credit card number 123 is not unlike matching of any otherdata related to the user 102 and various account information. Onceobtained by the payment provider system 180, the credit card number 123may then be communicated along various network pathways to facilitatecompletion of the purchase transaction.

In this regard, as shown in FIG. 3, the credit card number 123 may becommunicated from the payment provider system 180 back to the merchantsystem 140 via the network 160. The merchant system 140 thencommunicates the credit card number 123 via the network 160 to theissuer system 170 where the credit card number 123 is matched to theassociated credit card account 172 to permit verification andauthorization (acceptance or decline) of the credit card. Acceptance ordecline notification of the credit card is then communicated back to themerchant system 140 via the network 160 to facilitate completion of thepurchase transaction.

Alternatively, as shown in FIG. 4, the credit card number 123 iscommunicated from the payment provider system 180 to the issuer system170 via the network 160 where the credit card number 123 is matched tothe associated credit card account 172 to permit verification andauthorization (acceptance or decline) of the credit card. Acceptance ordecline notification of the credit card is then communicated back to thepayment provider system 180 via the network 160 where the notificationis further communicated from the payment provider system 180 to themerchant system 140 to facilitate completion of the purchasetransaction.

In still another network scheme, as shown in FIG. 5, the credit cardnumber 123 is communicated from the payment provider system 180 to theissuer system 170 via the network 160 where the credit card number 123is matched to the associated credit card account 172 to permitverification and authorization (acceptance or decline) of the creditcard. Acceptance or decline notification of the credit card is thencommunicated back from the issuer system 170 via the network 160 to themerchant system 140 to facilitate completion of the purchasetransaction.

FIG. 6, shows one embodiment of a method 600 for facilitating afinancial transaction over a network including a passphrase accountidentifier in reference to a payment provider system. In this regard,upon user instruction, the service application 126 may be installedand/or run on the client device 120 to access at least one merchantwebsite 141 via a related merchant system 140 to search the accessedmerchant website 141 and view one or more items for purchase.

Next, the user 102 may generate a purchase request for at least one itemby selecting the at least one item from the merchant's site 141 andproceed to checkout. Methods of item selection (product and/or service)and communication of the purchase request including user information,merchant information, and selected item information to the paymentprovider system 180 for payment processing is generally well-known inthe art.

Upon selection of one or more funding instruments for the purchase ofthe at least one item, the user 102 is further prompted to provide tothe merchant system 140 a passphrase account identifier 121 as arelatively more easily remembered substitute for the sixteen digitcredit card number 123 to enable users to conduct a payment transactionin more efficient manner.

Once received by merchant system 140, the passphrase account identifier121 may be communicated and received, via the network 160 by the paymentprovider system 180 (block 605) where the passphrase account identifier121 is matched to user information including the corresponding creditcard number 123 (block 610). In this regard, as encryption anddecryption techniques and/or technology is not required, the process ofmatching passphrase account identifier 121 to the corresponding creditcard number 123 is not unlike matching of any other data related to theuser 102 and various account information.

Next, the credit card number 123 is communicated from the paymentprovider system 180 to the issuer system 170 via the network 160 (block615) where the credit card number 123 is matched to the associatedcredit card account 172 to permit verification and authorization(acceptance or decline) of the credit card. Acceptance or declinenotification of the credit card is then communicated back and receivedby the payment provider system 180 via the network 160 (block 620) wherethe notification is further communicated from the payment providersystem 180 to the merchant system 140 (block 625) to facilitatecompletion of the purchase transaction.

Although described in various embodiments as not requiring the use ofencryption/decryption techniques and technologies, persons of ordinaryskill in the art will understand that in alternative embodiments all orany part of the payment network pathways described herein may employ theuse of cryptosystems, i.e., public and private key technology, includingthe use of Secure Sockets Layers protocol and/or Secure HTTP (S-HTTP)protocol for transmitting information such as payment card numbers andthe like over public networks such as the Internet between individuals,systems, etc., may be utilized without departing from the spirit of thedisclosed subject matter.

In accordance with various embodiments of the invention, a computerdevice or system, such as systems 120, 140, 170 and 180 described hereinand which may further include a personal computer and/or a networkserver, includes a bus or other communication mechanism forcommunicating information, which interconnects subsystems andcomponents, such a as processing component (e.g., processor,micro-controller, digital signal processor (DSP), etc.), system memorycomponent (e.g., RAM), static storage component (e.g., ROM), disk drivecomponent (e.g., magnetic or optical), network interface component(e.g., modem or Ethernet card), display component (e.g., CRT or LCD),input component (e.g., keyboard), and cursor control component (e.g.,mouse or trackball). In one implementation, disk drive component maycomprise a database having one or more disk drive components.

In accordance with embodiments of the invention, the computer systemperforms specific operations by a processor executing one or moresequences of one or more instructions contained in a system memorycomponent. Such instructions may be read into system the memorycomponent from another computer readable medium, such as a staticstorage component or a disk drive component. In other embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement the subject matter disclosed herein.

Logic may be encoded in a computer readable medium, which may refer toany medium that participates in providing instructions to the processorfor execution. Such a medium may take many forms, including but notlimited to, non-volatile media, volatile media, and transmission media.In various implementations, non-volatile media includes optical ormagnetic disks, such as disk drive component, volatile media includesdynamic memory, such as system memory component, and transmission mediaincludes coaxial cables, copper wire, and fiber optics, including wiresthat comprise bus. In one example, transmission media may take the formof acoustic or light waves, such as those generated during radio waveand infrared data communications.

Some common forms of computer readable media includes, for example,floppy disk, flexible disk, hard disk, magnetic tape, any other magneticmedium, CD-ROM, any other optical medium, punch cards, paper tape, anyother physical medium with patterns of holes, RAM, PROM, EPROM,FLASH-EPROM, any other memory chip or cartridge, carrier wave, or anyother medium from which a computer is adapted to read.

In various embodiments, execution of instruction sequences to practicethe invention may be performed by computer system. In various otherembodiments of the invention, a plurality of computer systems coupled bycommunication link (e.g., network 160 of FIG. 1, LAN, WLAN, PTSN, orvarious other wired or wireless networks) may perform instructionsequences to practice embodiments in coordination with one another.

The computer system may transmit and receive messages, data, informationand instructions, including one or more programs (i.e., applicationcode) through a communication link and a communication interface.Received program code may be executed by the processor as receivedand/or stored in disk drive component or some other non-volatile storagecomponent for execution.

Where applicable, various embodiments provided by the present disclosuremay be implemented using hardware, software, or combinations of hardwareand software. Also, where applicable, the various hardware componentsand/or software components set forth herein may be combined intocomposite components comprising software, hardware, and/or both withoutdeparting from the spirit of the present disclosure. Where applicable,the various hardware components and/or software components set forthherein may be separated into sub-components comprising software,hardware, or both without departing from the scope of the presentdisclosure. In addition, where applicable, it is contemplated thatsoftware components may be implemented as hardware components andvice-versa.

Software, in accordance with the present disclosure, such as programcode and/or data, may be stored on one or more computer readablemediums. It is also contemplated that software identified herein may beimplemented using one or more general purpose or specific purposecomputers and/or computer systems, networked and/or otherwise. Whereapplicable, the ordering of various steps described herein may bechanged, combined into composite steps, and/or separated into sub-stepsto provide features described herein.

The foregoing disclosure is not intended to limit the present inventionto the precise forms or particular fields of use disclosed. It iscontemplated that various alternate embodiments and/or modifications tothe present invention, whether explicitly described or implied herein,are possible in light of the disclosure.

Although the method(s)/step(s) are illustrated and described herein asoccurring in a certain order, the specific order, or any combination orinterpretation of the order, is not required. Obvious modifications willmake themselves apparent to those of ordinary skill in the art, all ofwhich will not depart from the essence of disclosed subject matter, andall such changes and modifications are intended to be encompassed withinthe appended claims.

What is claimed is:
 1. A system, comprising: an identification databaseof a payment provider server that stores a plurality of fundinginstrument identifiers corresponding to a plurality of passphraseidentifiers; a communication interface of the payment provider serverthat receives a user request over an electronic network to use apassphrase identifier pre-designated for a user account; and one or morehardware processors of the payment provider server that: determines oneor more characters of the passphrase identifier; determines acorresponding funding instrument identifier from the plurality offunding instrument identifiers based at least on the one or morecharacters; determines an authorization to use the funding instrumentidentifier based at least on a verification of the user request, whereinthe authorization indicates an acceptance or a decline to use thefunding instrument identifier; and transmits to a remote system anotification based at least on the acceptance or the decline to use thefunding instrument identifier, wherein the transmittal causes thenotification to be displayed on a graphical user interface (GUI) of aclient device in communication with the remote system.
 2. The system ofclaim 1, wherein the funding instrument identifier is a credit cardnumber.
 3. The system of claim 1, wherein the remote system is amerchant system, and wherein the client device is a merchant deviceconfigured to process a purchase for the user account based at least onthe notification.
 4. The system of claim 1, wherein the remote systemcomprises a credit issuer system configured to provide an indication ofan available amount for the user account based at least on theacceptance or the decline to use the funding instrument number.
 5. Thesystem of claim 1, wherein the client device comprises a user deviceconfigured to access the user account and modify the passphraseidentifier based at least on one character of the one or morecharacters.
 6. The system of claim 1, wherein the client devicecomprises a merchant device configured to apply the funding instrumentidentifier to process a transaction for the user account.
 7. The systemof claim 1, wherein the one or more characters comprise analpha-numerical combination of characters.
 8. The system of claim 1,wherein the one or more characters comprise upper case and lower casecharacters.
 9. A non-transitory machine-readable medium comprising aplurality of machine-readable instructions that, when executed by one ormore hardware processors of a network server, are configured to causethe network server to perform operations comprising: receiving a userrequest over an electronic network to use a passphrase identifier,wherein the passphrase identifier is modifiable for a user account;determining a corresponding funding instrument identifier from aplurality of funding instrument identifiers based at least on one ormore characters of the passphrase identifier; communicating with aremote system to determine an authorization to use the fundinginstrument number based on an amount available associated with thefunding instrument number, wherein the authorization indicates anacceptance or a decline to use the funding instrument identifier; andtransmitting a notification to the remote system based at least on theacceptance or the decline to use the funding instrument identifier,wherein the transmitting causes the notification to be displayed on agraphical user interface (GUI) of a client device in communication withthe remote system.
 10. The non-transitory machine-readable medium ofclaim 9, wherein the remote system comprises a credit issuer systemconfigured to determine the amount available associated with the fundinginstrument number, and wherein the client device comprises a merchantdevice configured to process a purchase for the user account with atleast a portion of the amount available.
 11. The non-transitorymachine-readable medium of claim 9, wherein the remote system comprisesa credit issuer system configured to provide the available amount to theuser account based at least on the acceptance or the decline to use thefunding instrument number.
 12. The non-transitory machine-readablemedium of claim 9, wherein the client device comprises a user deviceconfigured to access the user account and modify the passphraseidentifier based on at least one character of the one or morecharacters.
 13. The non-transitory machine-readable medium of claim 9,wherein the client device comprises a merchant device configured to usethe funding instrument identifier to process a transaction for the useraccount.
 14. The non-transitory machine-readable medium of claim 9,wherein the one or more characters comprise an alpha-numericalcombination of characters.
 15. The non-transitory machine-readablemedium of claim 9, wherein the one or more characters comprise uppercase and lower case characters.
 16. A method, comprising: maintaining,by a network server, a plurality of funding instrument identifiers thatcorrespond to a plurality of passphrase identifiers; receiving, by acommunication interface of a network server, a user request generated bya user device, wherein the user request includes a passphraseidentifier; and determining, by a hardware processor of the networkserver, a corresponding funding instrument identifier from a pluralityof funding instrument identifiers corresponding to a plurality ofpassphrase identifiers based at least on one or more characters of thepassphrase identifier; determining, by the hardware processor, anauthorization to use the funding instrument identifier based at least onthe user request, wherein the authorization indicates an acceptance or adecline to use the funding instrument identifier; and transmitting, bythe communication interface, a notification to a remote system based atleast on the acceptance or the decline to use the funding instrumentidentifier, wherein the transmitting causes the notification to bedisplayed on a graphical user interface (GUI) of the user device incommunication with the remote system.
 17. The method of claim 16,wherein the remote system comprises a merchant system, the methodfurther comprising processing a purchase with the merchant system basedat least on the acceptance to use the funding instrument identifier. 18.The method of claim 16, wherein the remote system comprises a creditissuer system configured to determine an amount available for the useraccount to process a transaction, the method further comprising:communicating with the credit issuer system to deteiniine an indicationof the amount available to the user account based at least on theacceptance to use the funding instrument number; and transmitting theindication of the amount available to the user device.
 19. The method ofclaim 16, further comprising modifying at least one character of the oneor more characters based on a user input received by the GUI interface.20. The method of claim 16, wherein the one or more characters comprisesan alpha-numerical combination of characters, and wherein the one ormore characters comprises upper case and lower case characters.